[ 1 ] About this Essay.....
[ 2 ] About Dead Listings...
[ 3 ] Cracking
by 'passive' and 'live' approaches...
[ 4 ] A general introduction to 'Sections'
found within dead Listings...
[ 5 ] How memory (RAM) is organized...
[ 6 ] About W32Dasm - 'Dead List' creator...
[ 7 ] ....
[ 8 ] ....
About
this Essay...
This 'essay' is still UNFINISHED and
still in a rough draft form, I've posted it on my homepage so that
what information has already been covered will at least help you now until
I've been able to finish it. The way it's turning out it looks set to becoming
a newbies 'manual' on 'Dead Listings'. If this happens then depending
on YOUR response will deiced if it's worth me converting this web page
into a full blown .HLP file. This has many advantages which besides being
compressed so therefore much quicker for you to download, you would then
be able to 'give copies to your friends' without them requiring a web browser
to read this document.
About
Dead Listings...
There is no mystery or secrecy surrounding 'Dead Listings' yet they remain under used and often ignored by many novice crackers. Lets see if we can dispel a few mis-conceptions and bring this useful form of information right into the open where it belongs.
Dead listings refer to the fact that we can
create a dissembled listing ( the source code ) of almost any program currently
available, regardless of wether it's a MS-DOS or Windows program.
Dead listings comprises of a single text
file that describes in the form of Assembly Language, every instruction
that the program is expected to use or execute. Contrary to popular belief,
you don't need to understand Assembly Language inside out to use dead listings,
in fact, knowing only a few important Assembly instructions and combining
these with a few guidelines will help you to understand your target program
far better than just using Softice!.
Think of 'dead listings' as a map to an unexplored city, it will tell you where all the code routines are in relation to each other and from a cracker's point of view, where all the important sections of code that are related to your target program's protection system(s) are kept. Not everyone can read a map but almost everyone can understand that a road is a road and a building is building so in dead listings we can see and know what Shareware messages look like, they are the text messages that often say "Please register..." and "You 30 days evaluation period has expired". Dead listings more often than not will not only show you these messages and many more besides but exactly where they are in your target program. Think of these messages as sign posts.
Before examining the actual 'dead listings' themselves in any detail lets us first look at the advantages and dis-advantages of using the 'live' and 'passive' approaches to cracking.
Cracking
by 'passive'
and 'live' approaches.
There are two approaches we can use to *cracking* a program, the first is often called the 'live' approach, which involves using a Debugger such as Softice to trace through the program's code step-by-step as the program is running on our computer. The second approach is commonly known as the 'passive' approach, where instead of using a debugger such as Softice to trace through the program's code we instead, use a program such as W32Dasm to create a 'Dead listing' of our target program, where WE then work out how the program operates.
The 'Live'
approach to cracking....
In general, it's accepted that we will be
using a debugger such as Softice to take full control over our target program,
by full control I mean we can follow each Assembly instruction the program
takes one step at a time if we chose.
Softice is a program that runs in the background
of Windows, it has to in order that it can take full control over our target
program and Windows itself. Like any software you use, understanding how
it works is only part of being able to use it properly, you also have to
have a fair understanding on the information it gives you!. What's the
point in assigning a value to say the EAX register if you don't know the
reasons why!
Main advantages of 'live'
cracking over 'passive' cracking .
In 'live' cracking... You can directly control the way the program 'thinks' and therefore 'behaves' by manipulating the values contained within your computer's 'Registers'.
In passive cracking..
You have no control what-so-ever over the target program and therefore
no access to any of your computer's registers.
In 'live' cracking...
Softice automatically takes our attention to other sections of code
within the target program as we follow it line-by-line, instruction-by-instruction.
Mistakes in following the program's normal path of execution is rare.
In passive cracking.. We must take extra care in following all the *possible* combinations of decision branches the target program makes in order to minimize mistakes in identifying possible routines connected with the protection system. Many protection systems use 'dummy' sections of code that lead nowhere in order to try and wear down the cracker before they reach the 'bingo' code!
In 'live' cracking...
We can 'test' possible patches to the program
without worrying about changing the program stored on our hard disk. Changes
to the program in memory remain only so long as the program is running.
As soon as we quite the program then any/all changes to the target program's
code is also lost, therefore allowing us to quickly and with minimal fuss,
make as many changes to the target program as we like without consequence.
In passive cracking..
Our task is not to try out any patches, only
to identify *possible* program locations that could be patched to suite
our needs.
In 'live' cracking... We can go and explore almost any type of program code such as .DLL (Dynamic Linked Library) files that increasingly play an important role in many programs currently available today. .DLL's are treated differently to normal .EXE files and being able to easily examine these files helps considerable our understanding of some programs that rely on these types of files for their protection systems. TimeLock32 is the name of a well known Protection System favored by many Software Houses to protect their 'software' which uses the TL32V2.DLL file to house it's protection system in.
In passive cracking..
DLL files are not always correctly disassembled
correctly (Certainly true for W32Dasm) in so much that it's not always
possible to know where this file will be loaded into the computer's memory.
Therefore the 'offset Addresses' shown will be wrong which then makes life
a little difficult if you wish to patch this type of file. Another
BIG problem associated with Dead Listings is that they can't correctly
disassemble any file (EXE,DLL) that has been compressed or encrypted, while
in 'live' cracking
this is not a problem since the compressed/encrypted code will already
be de-compressed/unencypted by the time Softice breaks in.
The 'Passive' approach to cracking....
In the 'Crackers' community it's generally accepted that there are only two possible programs that produce *good* dead listings, IDA Pro and W32Dasm.
IDA Pro is the favorite Disassembler of the
more *experienced* crackers though not always. W32Dasm, because it
runs in Win'95 (IDA Pro is a MS-DOS program) and produces IMO much better
Dead Listings than IDA Pro and therefore, makes it easier to follow is
the preferred tool for newbies including myself.
Main advantages of
'passive' cracking over 'live'
cracking...
In passive cracking..
We have an ASCII text file in the form of
a 'dead listing' of our target program, which in turn allows to us
to load this text file into a text editor such as Ultra Edit (Notepad can't
handle files greater than 64K, while our dead listings can and often be
many megabytes in size) for the purpose of adding comments to code sections,
or to perform lightning searches of specific code instructions. If, you
know that a particular routine within the target program performs a task
such as the printing of text messages then you can update all occurrences
of any jump or call instructions that sends the program to this message
routine and replace the calling address to say "Display text Message".
Example 1.
Change all occurrences of address 0040345 to "Display text Message"
Call 00401345 -----------> Call Display text Message
JZ 00401345 -----------> JZ Display text Message
JNZ 00401345 -----------> JNZ Display text message
In 'live' cracking... What you see is what you get. Yes you can perform searches on code instructions but unless you know exactly where your target program starts in memory and where it ends then any searches you make will also include areas of memory outside of the target program's code. Unless you have the source code to your target program (highly unlikely!) then the only visual 'clues' you'll get from the target program's code will be from the system calls to functions such as MessageBox(A), getLocalTime(A), GetWindowtext(A) etc which will only be seen if you've setup Softice properly at Bootup time through it's Winice.DAT file.
In passive cracking..
We can produce 'hard copys' from our dead
listing using a printer, this is not always necessary but it's nice to
know the facility is there if you do need it. If your writing an
essay about cracking a particular program then having a 'Dead Listing'
that you can cut and paste sections of code into your .HTM document makes
a difficult job of manually typing the code by hand into a doddle.
In 'live' cracking...
Making hard copy's of your target program
is not possible but more importantly, it's not necessary, since we're must
always remember that 'live' cracking is on-going project that lends itself
better to you making notes by hand as you examine in detail, the inner
void of your target program.
A
general introduction to 'Sections' found within Dead Listings.
Typically, a dead listing will be split
up into many different sections.
For example, many programs rely on using routines or functions (sections of code that perform a specific task) that are already available outside of the program itself and are kept in special files called .DLL's (Dynamic Linked Library's).
Windows 3.X and above uses many such files and saves the programmer(s) from having to create these routines over and over again in their programs if all they have to do is call upon the routine(s) stored within a .DLL file. Visual Basic programs are a classic example of programs running almost entirely on .DLL files.
So in a typical W32Dasm dead listing we have
a section of code that shows us what .DLL files are used by the target
program and just as importantly, what functions or routines are used.
Example 1.
This section of our dead listing shows
us what .DLL files are used by our target program.
+++++++++++++++++++ IMPORTED
FUNCTIONS ++++++++++++++++++
Number of Imported Modules
= 3 (decimal)
Import Module
001: KERNEL32.dll
Import
Module 002: USER32.dll
Import
Module 003: ADVAPI32.dll
Example 2.
This section of our dead listing shows us what functions or routines are used from the above .DLL files shown above.
+++++++++++++++++++ IMPORT MODULE DETAILS +++++++++++++++
Import Module 001: KERNEL32.dll
Addr:00018346 hint(0000)
Name: VirtualQuery
Addr:00018356
hint(0000) Name: HeapFree
Addr:00018362
hint(0000) Name: GlobalAlloc
Addr:00018370
hint(0000) Name: WideCharToMultiByte
Addr:00018386
hint(0000) Name: HeapAlloc
Addr:00018392
hint(0000) Name: CloseHandle
Addr:000183A0
hint(0000) Name: GetFileSize
Addr:000183AE
hint(0000) Name: GlobalUnlock
Addr:000183BE
hint(0000) Name: WriteFile
Addr:000183CA
hint(0000) Name: ExitProcess
Addr:000183D8
hint(0000) Name: FindResourceA
Addr:000183E8
hint(0000) Name: FreeEnvironmentStringsA
Addr:00018402
hint(0000) Name: FreeResource
Addr:00018412
hint(0000) Name: GetACP
Addr:0001841C
hint(0000) Name: GetCPInfo
Addr:00018428
hint(0000) Name: CreateFileA
Addr:00018436
hint(0000) Name: GlobalMemoryStatus
Addr:0001844C
hint(0000) Name: GlobalFree
Addr:0001845A
hint(0000) Name: GetVersionExA
Addr:0001846A
hint(0000) Name: lstrcatA
Addr:00018476
hint(0000) Name: GetFileType
Addr:00018704
hint(0000) Name: Sleep
Addr:0001870C
hint(0000) Name: TlsAlloc
Addr:00018718
hint(0000) Name: TlsFree
Addr:00018722
hint(0000) Name: TlsGetValue
Addr:00018730
hint(0000) Name: TlsSetValue
Addr:0001873E
hint(0000) Name: UnhandledExceptionFilter
Addr:0001875A
hint(0000) Name: VirtualAlloc
Addr:0001876A
hint(0000) Name: VirtualFree
Import Module 002: USER32.dll
Addr:00018778 hint(0000)
Name: SetWindowPos
Addr:00018788
hint(0000) Name: SetTimer
Addr:00018794
hint(0000) Name: SetFocus
Addr:000187A0
hint(0000) Name: SetDlgItemTextA
Addr:000187B2
hint(0000) Name: PostThreadMessageA
Addr:000187C8
hint(0000) Name: MessageBoxA ; A good Softice
breakpoint
Addr:000187D6
hint(0000) Name: LoadStringA
Addr:000187E4
hint(0000) Name: GetWindowRect
Addr:000187F4
hint(0000) Name: GetFocus
Addr:00018800
hint(0000) Name: GetDlgItemTextA ; A good Softice
breakpoint
Addr:00018812
hint(0000) Name: GetDlgItem
Addr:00018820
hint(0000) Name: EnumThreadWindows
Addr:00018834
hint(0000) Name: EndDialog
Addr:00018840
hint(0000) Name: KillTimer
Addr:0001884C
hint(0000) Name: EnableWindow
Addr:0001885C
hint(0000) Name: DialogBoxParamA
Addr:0001886E
hint(0000) Name: SetWindowTextA
Import Module
003: ADVAPI32.dll
*
These functions handle the reading and writing of information to our *
*
System Registry file, and can sometimes make good softice breakpoints *
Addr:00018880 hint(0000)
Name: RegSetValueExA
Addr:00018892
hint(0000) Name: RegDeleteKeyA
Addr:000188A2
hint(0000) Name: RegQueryValueExA
Addr:000188B6
hint(0000) Name: RegEnumKeyExA
Addr:000188C6
hint(0000) Name: RegCreateKeyExA
Addr:000188D8
hint(0000) Name: RegCloseKey
So knowing what functions\Routines we can and can't use in Softice is worth knowing but from our point of view it's not all that important.
The next thing you'll need to know...
+++++++++++++++++++ ASSEMBLY CODE LISTING
++++++++++++++++++
//********************** Start of Code
in Object CODE **************
Program Entry Point = 00401000 (Validate.dll
File Offset:0000FC00)
In W32Dasm we are told where the program's
code starts in memory, however, this does NOT mean 'where' the program
will begin executing from when it's first run, this could be anywhere and
is rarely the same for different programs.
A
general introduction to how memory (RAM) is organized.
Confusion raises it's
ugly head amongst newbies on how the assembly code relates to memory address
in our computers and from just my daily emails this type of question is
asked many times in as many ways. Well ok, here goes my simplified explanation
of this mystery and how I make sense of all this..
When you create a dead listing W32Dasm has no way of knowing exactly where our target program will be loaded into our computers memory, this factor depends on the following conditions:-
1. The amount of overall RAM (Random Access memory) which Win 3.X or above has at its disposal.
2. The number of 'other' programs you may have silently running in the background like NotePad or Word for Windows or Softice etc are given priority over your target program so that Windows then has to find 'other' free memory locations to run your target program. Since your computer's memory is mapped into pre-defined memory blocks, each capable of running a single program we have no way of guaranteeing which of these 'blocks' our target program will be assigned to.
In order to better visualize the computer's memory try thinking of your computer's memory as an empty book.
Now within this book are a number of blank pages, and on each page is the Page Number, which in computer terms is known as Memory Address.
In order to help you further, this book has each page of this book line numbered, starting from 00000000 to FFFFFFFF which in computer terms is known as Memory Offset Address.
So we have a Page
No known as Memory Address
and the line numbering of each page known as Memory
Offset Address.
Example 3. - A 'Page' Of Memory.
<Memory Address> < Colon> <Memory offset Address>
0000013F
: 00000001
0000013F
: 00000002
0000013F
: 00000003
0000013F
: 00000004
So that the computer doesn't get confused we us a COLON <:> to signify the end of the <Memory Address> and the start of the <Memory Offset Address>.
Here's what a full memory location address might look like:-
Memory Address Colon Memory Offset Address
00F45324 : 00400000
<Page No>
:
<Line No>
In dead listings we don't care where Windows will be placing our target program, ie in which 'Page', because in whichever 'page' it loads our target program the Line renumbering <Memory Offset Address> will ALWAYS be the same, and it's this <Memory Offset Addresses> that W32Dasm uses in it's dead listings.
Don't worry about how big these 'pages' of memory are, or how many lines of code we can have on each 'page' just accept for now that as far as we're concerned, Memory offset Addresses are no more than line numbers and that W32Dasm uses line numbers in the Assembly code listing (called Dead Listings) to calculate where jumps and calls statements will take the program to.
ALL computer programs
regardless wether it's a game or utility or whatever are all made up of
Decisions then followed by TWO possible Actions. If
you press a button or type something from your keyboard then the program
will Decide what course of Action it will take based on what
YOU just did.
Example 4. - Decisions followed by two possible Actions.
If you type in a serial number into a program then press the OK button then the program may make the following decisions and Actions:-
Question: Did you press the 'Cancel' button?
Answer 1. If
YES then ignore serial number and display a warning type message.
Answer 2. If
NO then lets check the serial number to see if its valid.
Question: Is serial number valid?
Answer 1. If NO then
display a message telling you to try again.
Answer 2. If YES then
allow program to be registered.
The above is an extremely
simple overview of what a program does, in reality it does these sort of
decisions and actions all the time the program is running and in much more
depth but at least I hope, you'll start to understand the general concept
of decisions followed by one of two possible outcomes.
About
W32Dasm
The two most popular programs used by crackers
to create 'Dead Listings' are:-
W32Dasm V8.9
IDA Pro V3.75
For this introduction I shall concentrate on using W32Dasm as our major source of creating 'Dead Listings' although much of this essay can be converted over to IDA with perhaps only minor changes in operations.
So what is W32Dasm?.
W32DASM
Synopsis: W32DASM v.8.9 is a combined disassembler/debugger
that totals up to 2.13MB. The disassembler allows viewing of one file at
a time; starting a debug
process allows the disassembled file to
be run and patched in memory (debug mode
commands are marked with D, below). Features
include import and export function
tables, reference tables for strings, menus,
and dialog boxes, hex dumps of data and code segments, and jump/call branching.
The debugger is standard fare with the added features of in-memory code
patching and Windows API call "detailing"--a valuable feature that gives
the parameters and returns of any API call made by the program.
Usage: W32Dasm has a user-friendly interface that is pretty easy to figure out. The key points are to check out the Refs and Functions menu items, each of which gives a list of relocations/resources within the disassembled file that may be jumped to by double-clicking the list item. The Hex Data item would be more useful if it included resources (for all those Delphi/VB apps out there), but it does allow you to re-interpret the code and data (in your head) if need be. Execute Text and Goto are both worth checking out; the first allows you to follow jumps and calls (also available via keystrokes and on-screen buttons), the second will jump immediately to the entry point or a specific code location (no file header, unfortunately).
Debugger: W32Dasm has a serviceable debugger that has some nice features, but is rather difficult ot use. The benefits include a data display that allows you to easily browse the data pointed to by different registers (e.g., ecx, ecx+0004, ecx +, 0008, etc), an API feature that displays the parameters and returns of API calls made by the program, and an integrated "copy" option that allows either of the two data displays, a list of active .DLLs, a message/command history, and a current register or memory location to be copied to the Windows clipboard. The downside is that the User Interface is a nightmare; the combination of the three staggered windows (reminiscent of newer "visual" IDEs) and the swarm of tiny check boxes and buttons makes the whole thing visual disorienting you pretty much have to go in with BRW and modify the UI to suit your taste.
Shortcuts
Ctrl-L
Load Process
Ctrl-T Terminate Process (D)
F5
Auto Step Into(D)
F6 Auto Step Over(D)
F7
Step Into(D)
F8 Step Over(D)
F9
Run Process(D)
Space Pause Process(D)
F2
Breakpoint Toggle (D) Ctrl-C
Copy Selection
Ctrl-S,F
Find Text
F3 Find Next
Ctrl-S
Goto Code Start
F10 Goto Entry Point
F11
Goto Page
F12 Goto Code Location
Lft Arrow Execute
Jump
Ctrl Rt Arrow Return From Jump
Lft Arrow Execute
Call
Rt Arrow Return From Call
W32Dasm is a Windows 95 program, much preferred by newbies because it has an easy to understand interface and the dead listings created are also in an easy-to-understand format. You cannot disassemble MS-DOS programs with W32Dasm.
IDA Pro on the other hand is a MS-DOS program,
it's very much more powerful than W32Dasm and is often able to show difficult
sections of code that W32Dasm fails to handle properly. IDA's interface
is rather dated and will look quite daunting to those not familiar with
such programs and the output too will also look unfamiliar to those used
to seeing W32Dasm's smart looking dead listings.
|
|
Please keep checking in for additions..
Please send comments/ommisions etc about
this essay to: ">The
Sandman
| [ Return ] |
Essay by:
">The Sandman
Page Created: 4th August
1998